Loopback capability for Bi-directional multi-protocol label switching traffic engineered trunks

ABSTRACT

A system and method for introducing a loopback capability for Multi-Protocol Label Switching (MPLS) bi-directional traffic trunks are discussed. MPLS is an emerging technology, which integrates Internet Protocol (IP) routing with label switching techniques. MPLS intends to provide new capabilities in the area of traffic engineering for IP networks. These traffic engineering capabilities will have to be combined with a set of complementary operation, administration and maintenance (OA&amp;M) functions for effectively managing and operating MPLS-based networks. One such function is loopback. A loopback function provides the capability to transmit a OA&amp;M packet on one or more segments of a bi-directional traffic trunk (BTT) in a MPLS network. Using a loopback function, parameters of a BTT, such as connectivity, delay and other Quality of Service (QoS) parameters, can be tested. The system and method provide different techniques for implementing loopback in an MPLS network.

This is a continuation of U.S. patent application Ser. No. 09/589,464,filed Jun. 7, 2000, which is hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates generally to network operation,administration, and maintenance (OA&M) functions for communicationnetworks. More particularly, the present invention relates to a loopbackfunction for networks employing label switching techniques.

BACKGROUND OF THE INVENTION

A typical digital communications network has a network architecture thatis based upon the Open Systems Interconnection (OSI) Reference Model forproviding communication between a multiplicity of interconnected digitalend systems or “nodes.” The OSI Reference Model divides networkingprotocols into seven layers, which, in ascending order of abstraction,are: 1) the physical layer, 2) the data-link layer, 3) the networklayer, 4) the transport layer, 5) the session layer, 6) the presentationlayer, and 7) the application layer.

Local area networks (LANs), i.e., a short-distance communicationsnetwork, operate at layer 2 in the OSI model. Routers operate at layer 3in the OSI model and may connect two LANs or other types of networkshaving different protocols. More specifically, routers at the networklayer terminate local data-link layer protocols and utilize networklayer addresses and data frame restructuring to communicate with eachother.

Internet Protocol (IP) is a typical layer 3 routing protocol. For IProuting, a router receives a packet and determines a next hop, i.e., thenext destination for the received packet in the path towards the finalpacket destination. Typically, each router in the path to the finaldestination of the packet analyzes the packet header for identifying thepacket's destination address and runs a routing algorithm fordetermining the next hop towards the identified destination address.

Multi-Protocol Label Switching (MPLS) optimizes conventional routingtechniques by assigning labels to a Forwarding Equivalent Class (FEC). AFEC is defined as a set of packets that can be handled equivalently forthe purpose of forwarding and thus is suitable for binding to a label.Once a binding between a FEC and a label is done, it is not necessaryfor each label switching router (LSR) in a label-switched path (LSP) ,i.e., a path through one or more LSRs followed by packets having thesame FEC, to analyze a received packet's IP header for determining thepacket's destination address. Instead, LSRs make forwarding decisionsbased on the label attached to the packet, and consequently, packets arerouted through the network faster.

MPLS is being developed for high-speed networks that, for example, areused by some Internet-service providers (ISPs). MPLS is currently beingstandardized by the MPLS Working Group of the IETF (Internet EngineeringTask Force).

FIG. 1 illustrates an MPLS packet having a data-link layer 8, MPLS shimheader 7, network layer 6 and a payload 5. MPLS uses a shim header 7between a data-link layer 8 and a network layer 6 for integrating IProuting with label switching. The MPLS architecture encapsulates an IPpacket in an MPLS shim header 7. The shim header 7 is placed between thedata-link layer 8 and the network layer 6 headers. MPLS can operate onany layer 2 media (e.g., ATM, FR, PPP), but MPLS currently serves onlythe IP client network layer. The shim header consists of a series oflabel stack entries. Each label stack entry contains a 20-bit labelfield 1, a 3-bit experimental field 2, a single bit field 3 indicatingthe bottom of the label stack and an 8-bit time-to-live (TTL) field 4.

Similar to conventional routing table entries, each LSR in a MPLSnetwork may include a forwarding table having next hop label forwardingentries (NHLFEs). Each NHLFE, among other information, contains thephysical interfaces or ports, the incoming label, and the outgoing labelfor the next hop for a received packet. A label in a label stack entryof a received packet is used as an index for retrieving a NHLFEcontaining the next hop for the received packet. Generally, the labelfrom the label stack entry on the top of the label stack is used toindex the NHLFEs in the LSR. After identifying the NHLFE for the nexthop, the outgoing label for the next hop, which is retrieved from theidentified NHLFE, is placed on top of the label stack for the packet,and the packet is transmitted to the next hop. This label switchingtechnique is used by the LSRs for routing MPLS packets through the MPLSnetwork.

FIG. 2 illustrates a reference topology for a typical MPLS network 45.MPLS network 45 includes a set of nodes or LSRs for performing MPLSrouting and forwarding. The LSRs in MPLS network 45 include intermediateLSRs and label-edge routers, e.g., LER 1 and LER 2. The set ofcontiguous nodes that an MPLS packet traverses in the MPLS network iscalled a Label Switched Path (LSP).

MPLS network 45 includes a bi-directional traffic engineering trunk(BTT) 42 having two traffic engineering trunks with the same endpoints,i.e., LER 1 and LER 2, and opposite directions of transmission. The twotraffic trunks that form BTT 42 traverse two unidirectionalexplicitly-routed label-switched paths (ER-LSPs) between LER 1 and LER2. An ER-LSP is a LSP defined by a management system or a single LSRthat is typically the ingress LSR for that particular direction oftransmission, e.g., LER 1 or LER 2. ER-LSPs are set up independent of IPshortest path routing algorithms. BTT 42 is formed of two traffic trunkstraversing two ER-LSPs in opposite directions. One traffic trunk flowsdownstream from ingress LER 1 towards egress LER 2 on one ER-LSP. Theother traffic trunk flows upstream from egress LER 2 towards ingress LER1 on the other ER-LSP. Consequently, BTT 42 traverses a completeround-trip path between LER 1 and LER 2.

It is envisioned that ER-LSPs, which form BTTs, will be set up forcarrying possibly hundreds to several thousands of individual IP flows.Hence, it is crucial to ascertain parameters of a BTT, such asconnectivity, delay and other quality of service (QoS) parameters thatmay effect traffic flow in the BTT.

MPLS describes six basic traffic engineering functions that can beperformed on a traffic engineering trunk: establish, activate,deactivate, modify attributes, reroute, and destroy. MPLS currentlylacks OA&M functions that can provide the ability for ascertainingparameters of a BTT. Hence, a need exists for a set of OA&M functions inMPLS that provide the ability for ascertaining parameters of a BTT.

Hosts use commands, such as Ping and Traceroute, in conjunction withInternet Control Message Protocol (ICMP) for diagnosing routingproblems. For example, a router unable to deliver a datagram can send anICMP message to a host that originated the datagram.

There is a proposed approach for diagnosing routing problems in MPLSnetworks that relies on layer 3 ICMP messages. This approach, however,can only be implemented if the layer 3 protocol is IP. Furthermore, thisapproach may be adequate for some OA&M functions (e.g, checkingcontinuity with Ping and Traceroute) from a host to another host orserver but will not be adequate for checking continuity and QoSattributes of a TE trunk. The OA&M functions for managing TE Trunks willhave to adapt to the coarser flow granularity of the TE trunks in orderto scale when used in large provider networks. Therefore, a need existsfor a set of MPLS-layer OA&M functions that provide the ability forascertaining the parameters of a BTT.

The present invention includes a loopback OA&M function, which canoperate independent of the layer 3 client protocols. That is, it can beused whether or not the layer 3 protocol is IP. If the layer 3 protocolis IP, then all the IP diagnostic tools such as Ping and Traceroute canbe used in combination with the proposed OA&M (in this case loopback)functions. An MPLS network having a loopback OA&M function has theability to test parameters of a BTT. A BTT must be tested prior toloading the BTT with user traffic to ensure, for example, that the BTTis connected and that the BTT has adequate QoS. In addition, the BTTmust be tested after being loaded with user traffic to detect data losscaused by a disconnection or inadequate QoS, and take appropriatecorrective action. A loopback function can perform double-endedconnectivity verification and test QoS. Thus, a loopback function cansimplify OA&M for MPLS networks and can potentially reduce unit cost forany MPLS-based network. Given the tremendous growth of IP traffic andpotential migration of circuit-switched and data traffic to an MPLS coretransport mechanism, a loopback traffic engineering function can havelarge impact on the way an MPLS-based network is managed and operated.

SUMMARY OF THE INVENTION

It is an aspect of the present invention to provide a loopback OA&Mfunction that can be introduced as an additional function to the MPLStraffic engineering framework or as part of a more comprehensive OA&Mframework in MPLS. An MPLS-layer loopback function, hereinafter referredto as a loopback function, is a OA&M function providing the capabilityfor testing parameters of traffic trunks in a MPLS network. For example,an originating LSR, i.e., an LSR constructing a loopback packet fortransmission on a specific BTT, can send a loopback packet downstream toa loopback LSR. A loopback packet is a OA&M packet intended to betransmitted, from a LSR constructing the loopback packet, downstream,i.e. from the constructing LSR towards a loopback LSR. A loopback LSR isan LSR that receives the loopback packet and performs a loopbackprocedure for transmitting the loopback packet upstream, i.e., towardsthe LSR that constructed the loopback packet. The LSR that constructedthe loopback packet, receives the loopback packet from the loopback LSR,and evaluates one or more BTT parameters using information provided bythe loopback packet. The loopback packet may be an in-band networkmanagement packet (INMP). An INMP is a label-switched network managementpacket that carries OA&M information and commands. Each LSR along theBTT, receiving the loopback packet, may process the loopback packet fortesting parameters of the BTT. For example, an LSR receiving a loopbackpacket for testing delay can perform delay measurements for the packet.Also, once the loopback packet is received by the originating LSR afterthe loopback procedure is performed, the originating LSR can ascertaintested BTT parameters using the received loopback packet.

It is another aspect of the present invention to provide a technique forperforming a loopback procedure in a loopback LSR.

It is still another aspect of the present invention to provide atechnique for processing an INMP.

In accordance with the present invention, there is provided a system andmethod for performing in-service and pre-service loopback functions inan MPLS network. An originating LSR establishes a BTT, and the loopbackfunction is activated at another LSR along the path of the establishedBTT. The LSR that has activated the loopback function performs aloopback procedure, and at least one parameter of the BTT is evaluatedby the originating LSR. If an evaluated parameter is equivalent to orexceeds a predetermined standard, then the BTT is activated. After theBTT is activated and loaded with user-traffic, at least one parameter ofthe activated BTT can be periodically tested.

The present invention further provides a system and method forprocessing an INMP. An LSR constructs and transmits an INMP downstreamtowards a loopback LSR. An LSR receives the INMP, identifies thereceived packet as an INMP, processes the INMP and determines whether itis the loopback LSR. If the LSR receiving the INMP is the loopback LSR,then the LSR performs a loopback procedure for transmitting the INMPupstream towards the LSR constructing the INMP.

The present invention further provides methods for performing a loopbackprocedure in a loopback LSR. An LSR receives an incoming packettravelling downstream on a BTT and identifies an incoming label from thereceived packet. In a first preferred embodiment of the presentinvention for performing a loopback procedure, the LSR replaces theidentified incoming label with an incoming label corresponding to areceived packet travelling upstream on the BTT. Then, the LSR determinesthe next hop for the received packet using an NHLFE for the replacedlabel. In a second preferred embodiment of the present invention forperforming a loopback procedure, instead of replacing the incominglabel, the LSR determines the next hop using a loopback label forwardingentry (LLFE) for the identified incoming label.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the accompanying figures in which like reference numeralsindicate similar elements and in which:

FIG. 1 is a diagram illustrating a format of a packet header used in aMPLS network;

FIG. 2 is a schematic block diagram illustrating a typical BTT within aMPLS network;

FIG. 3 is a schematic block diagram of a typical BTT within an MPLSnetwork of the present invention;

FIG. 4 is a schematic block diagram of a router of the presentinvention;

FIG. 5 is a flow diagram of a first preferred embodiment of the presentinvention for performing a loopback procedure in an LSR;

FIG. 6 is a flow diagram of a second preferred embodiment of the presentinvention for performing a loopback procedure in an LSR;

FIG. 7 is a flow diagram for performing a pre-service loopback function;

FIG. 8 is a flow diagram for performing an in-service loopback function;and

FIG. 9 is a flow diagram for processing loopback INMPs.

DETAILED DESCRIPTION

1. Label Switching Router Performing Loopback

FIG. 3 illustrates MPLS network 40 and NHLFEs for LSR 1 and LER B. Anoriginating LSR, such as ingress LER A, can activate a loopback functionin an intermediate LSR or a LER. As shown using loopback arrows 12 and13, FIG. 3 illustrates that either an intermediate LSR, such as LSR 1,or a LER, such as LER B, may be a loopback LSR. Using either LSR 1 orLER B as a loopback LSR, a loopback packet, transmitted on BTT 10 fromLER A, is transmitted back to LER A on BTT 10 from the loopback LSR.

FIG. 4 is a schematic block diagram of a preferred embodiment of an LSRperforming a loopback procedure in MPLS network 40. The LSR shown inFIG. 4 includes ports 50-53, processing circuitry 65 and switchingfabric 60. Each of ports 50-53 includes transmitting circuitry,receiving circuitry and packet assembly circuitry, as is known in theart. Ports 50-53 are connected to processing circuitry 65 throughswitching fabric 60. The switching fabric, for example, may be ahigh-speed bus and include one or more multiplexors and demultiplexors.Processing circuitry 65 includes a processor 61 and memory 62. Processor61 may include a high-speed processor and performs forwarding/routingfunctions. Memory 62 stores NHLFEs in a table or database fordetermining a next hop.

Typical operation of the LSR shown in FIG. 4 may include receivingincoming packets at ports 50-53. Packet information from the incomingpackets is sent to processing circuitry 65. Processing circuitry 65processes the packet information to determine the next hop for anincoming packet. For example, processing circuitry 65 can identify anincoming label for each packet, and retrieve an NHLFE corresponding tothe incoming label from a table stored in memory 62. The retrievedNHLFE, among other information, contains the label and the physical portfor sending the packet to the next hop. Then processing circuitry 65forwards the packet information with the new label through switchingfabric 60 to the port associated with the next hop. The packetinformation is assembled into an outgoing packet. The outgoing packet isthen transmitted to the next hop.

In a first preferred embodiment of the present invention for performinga loopback procedure at a loopback LSR, an incoming packet travellingdownstream on BTT 10 is received at a port on the LSR. Processingcircuitry 65 identifies the incoming label of the received packet. Thenprocessing circuitry 65 replaces the incoming label with an incominglabel corresponding to a received packet travelling upstream on BTT 10.This can be done since the routers are aware that the constituentunidirectional LSPs, which form the BTT, constitute a single logicalentity. Processing circuitry 65 retrieves the NHLFE associated with thereplaced incoming label, and the received incoming packet is transmittedto a next hop upstream on BTT 10.

In a second preferred embodiment for performing a loopback procedure ata loopback LSR, loopback label forwarding entries (LLFEs) are stored ina table or database in memory 62 in a loopback LSR. LLFEs provide thenext hop for a loopback packet. For example, instead of retrieving theNHLFE for the incoming label, processing circuitry 65 retrieves the LLFEfor the incoming label. Using the LLFE for the incoming label,processing circuitry 65 determines the next hop for loopback, and theincoming packet is transmitted to a next hop upstream on BTT 10. TheLLFEs may be constructed by every LSR immediately after a BTT isestablished. Alternatively, in order to save processor memory, LLFEs canbe constructed only by the loopback LSR immediately after receiving aloopback command. Also, in the latter method, LLFEs may be stored forthe duration loopback is activated in a loopback LSR.

FIG. 5 is a flow diagram for the first preferred embodiment of thepresent invention for performing a loopback procedure at an LSR. FIG. 5will be described using LSR 1 as a loopback LSR, as illustrated in FIG.3. Loopback arrow 12, in FIG. 3, illustrates a loopback procedureperformed at LSR 1. Also, elements of the loopback LSR illustrated inFIG. 4 will be used in the description of FIG. 5. In step 70, LSR 1receives a loopback packet from LER A on port 50 having incoming label102 in the loopback packet header. The packet information for theloopback packet is forwarded to processing circuitry 65. In step 71,processing circuitry 65 determines that the packet is a loopback packetfrom packet header information for the loopback packet, and identifiesitself as the loopback LSR for the received loopback packet travellingdownstream on BTT 10. Techniques for identifying loopback packets, suchas INMPs, are described in co-pending U.S. patent application Ser. No.TBD (Attorney Docket No. 3493.85735), previously incorporated byreference. In step 72, processing circuitry 65 replaces incoming label102 with incoming label 406 that corresponds to a packet received fromBTT 10 travelling upstream on BTT 10. In step 73, processing circuitry65 identifies the NHLFE associated with the replaced label 406. Forexample, processing circuitry 65 may index a table having NHLFEs andretrieve the NHLFE associated with replaced label 406. Processingcircuitry 65 determines the next hop using the identified NHLFE, and theloopback packet is transmitted to LER A. If per-interface label spacemethod is used (as opposed to per-platform label space), the loopbackpacket is label switched using the NHLFE associated with the interfacecorresponding to label 406 in FIG. 3.

FIG. 6 is a flow diagram for a second preferred embodiment of thepresent invention for performing a loopback procedure at a loopback LSR.FIG. 6 will be described using LSR 1 as a loopback LSR, as illustratedin FIG. 3. Loopback arrow 12, in FIG. 3, illustrates a loopbackprocedure performed at LSR 1. Also, elements of the loopback LSRillustrated in FIG. 4 will be used in the description of FIG. 6. In step80, LSR 1 receives a loopback packet from LER A on port 50 havingincoming label 102 in the packet header. The packet information for theloopback packet is forwarded to processing circuitry 65. In step 81,processing circuitry 65 determines that the packet is a loopback packetfrom packet header information, and identifies itself as the loopbackLSR for the received loopback packet travelling on BTT 10. In step 82,processing circuitry 65 identifies the LLFE associated with incominglabel 102. For example, processing circuitry may index a table havingLLFEs using incoming label 102, and retrieve the LLFE associated withincoming label 102. Processing circuitry 65 determines the next hopusing the identified LLFE, and the loopback packet is transmitted to LERA. If per-interface label space is used (as opposed to per-platformlabel space), the loopback packet is label switched using the LLFEcorresponding to the interface on which it has been received (i.e., theinterface corresponding to label 102 in FIG. 3).

The first and second preferred embodiments of the present invention forperforming a loopback procedure can be performed by an edge LSR, such asLER A or LER B, or an intermediate LSR, as described above. Also, thefirst and second preferred embodiments of the present invention forperforming a loopback procedure may be performed for an in-serviceloopback function, a pre-service loopback function and a remote loopbackfunction; the in-service, pre-service and remote loopback functions aredescribed in detail below.

2. Pre-Service and In-Service Loopback Functions

Pre-service and in-service loopback functions are two types of loopbackfunctions that may be performed on a MPLS network. The pre-serviceloopback function is performed prior to loading the BTT with usertraffic. For the pre-service loopback function, a loopback procedure isactivated in a target LSR (i.e., an LSR that is intended to receive anOA&M command), after establishing a BTT but before activating the BTT.For the in-service loopback function, a loopback procedure is performedat the loopback LSR after the BTT is activated, i.e., while a BTTcarries user traffic. The activated procedure for the in-service or thepre-service loopback function may, for example, be a loopback proceduredescribed in either of the first and second embodiments of the presentinvention for performing a loopback procedure. Both the pre-service andthe in-service loopback functions are useful for testing parameters of aBTT, e.g., connectivity, delay and other QoS parameters. For example, aloopback INMP may carry information that contains the address of eachtraversed LSR, starting with the originating LSR. Using the addressinformation in the loopback INMP, the path traversed by the loopback LSRmay be traced, and connectivity of the BTT may be verified.

OA&M commands, such as the one for activating a loopback procedure, maybe sent to the target LSR using in-band or out-of band techniques. Toactivate loopback out-of-band, for example, an “activate loopback”network management (NM) command may be sent from a NM system, e.g., aremote network station or an operator console connected to an LSR. Thecommand instructs the LSR to activate a loopback procedure for aspecific BTT, so the loopback function is performed for packetstravelling on the specific BTT. For activating loopback in-band, anoriginating LSR transmits an INMP, carrying, for example, an “activateloopback” command in its payload, to a target LSR. The target LSR, afterreceiving the INMP, activates a loopback procedure. Then, the target LSRmay send an acknowledgement INMP to the originating LSR indicating thatit has activated the loopback procedure.

The pre-service loopback function can be performed by activating aloopback procedure using an in-band or out-of-band command, e.g.,“activate loopback”. The LSR activating the loopback procedure may be aLER or an intermediate LSR. Once a procedure for performing loopback isactivated, a loopback INMP can be looped through a BTT for testingparameters of the BTT. For example, a loopback INMP can be used forascertaining round trip time (RTT) or delay of a BTT. A single clocksource at an originating ingress LSR may be used for measuring RTT.Also, loopback may be used for ascertaining connectivity, delay andother QoS parameters for a BTT.

FIG. 7 is a flow diagram of a preferred embodiment of the presentinvention for performing the pre-service loopback function. FIG. 7 willbe described using a LER, such as LER B shown in FIG. 3, as a loopbackLSR. Loopback arrow 13 in FIG. 3 illustrates a loopback procedureactivated at LER B for performing a loopback function. In step 200, BTT10 is established by LER A using a NM command. In step 201, prior toloading BTT 10 with user traffic, an LSR in the path of BTT 10 isselected for performing a loopback procedure. For example, if the entireBTT 10 needs to be evaluated, the opposite edge router, such as LER B,is selected. Otherwise, an intermediate LSR in BTT 10 is selected. Inthis example, a loopback procedure in LER B is activated using, forexample, an in-band or out-of-band “activate loopback” command. Then,LER A transmits a loopback packet, such as a loopback INMP, to LER B.LER B performs the loopback procedure for the received loopback packetand sends the packet upstream towards LER A. The loopback LER, LER B,may set a flag in the payload of the loopbacked INMP indicating that theINMP sent upstream is a loopbacked INMP. In step 202, LER A evaluates atleast one parameter of BTT 10. In step 202, LER A, after receiving theloopback packet from LER B, determines whether at least one parameter ofBTT 10, such as connectivity, delay, and/or other QoS parameters, isequivalent to or exceeds, i.e., is better than, predetermined standards.A predetermined standard may, for example, include a predeterminedtolerance, such as a delay tolerance, or a predetermined threshold, suchas a delay threshold or whether a BTT is connected. If one or moretested parameters pass, i.e., the tested parameters are equivalent to orexceed their respective predetermined standards, then a “deactivateloopback” command may be sent in-band or out-of-band to LER B in step203. For example, if delay is tested for BTT 10, and the predeterminedstandard is a delay threshold value, then the tested delay passes if thetested delay exceeds, i.e., the tested delay is less than the delaythreshold, or is equivalent to the delay threshold. One of ordinaryskill in the art, however, can readily set the predetermined standard,so the tested parameter must exceed the predetermined standard to pass.For example, if delay is tested for BTT 10, and the predeterminedstandard is a delay threshold value, then the tested delay must exceedthe delay threshold value, i.e., the tested delay must be less than thedelay threshold, for the tested delay to pass. Then BTT 10 is activatedin step 204, and BTT 10 is loaded with user traffic, if the at least onetested parameter passes. If one or more tested parameters fail, i.e.,one or more tested parameters are not equivalent or do not exceedrespective predetermined standards, notification is provided, forexample, alarms can be activated at the NM system, and/or BTT 10 isre-established, for example, using another ER-LSP. Then, the remainingsteps for implementing the pre-service loopback function are repeated.

As described above, the pre-service loopback function may be performedat a LER, so, for example, bi-directional connectivity for the entireBTT may be tested. Alternatively, the pre-service loopback function maybe performed at an intermediate LSR for trouble-shooting a BTT. Forexample, a trouble spot in a BTT can be isolated by progressivelyperforming a loopback function for consecutive portions of a BTT.

Additionally, when a procedure for performing loopback is activated forthe pre-service loopback function, a procedure for performing loopbackfor the remote loopback function can be activated at the same LSR. Theremote loopback function ensures continuity of signal for the remote LERduring pre-service BTT testing. The remote loopback function isillustrated with a remote loopback arrow 15 in FIG. 3 for LSR 1. If theremote loopback function is performed, a packet transmitted from LER Bwill be looped back to LER B. Therefore, LER A can test the portion ofBTT 10 between LER A and LSR 1, and LER B can test the remainingportions of BTT 10. A procedure for performing loopback for the remoteloopback function may, for example, include the procedures described inthe first and second preferred embodiments for performing a loopbackprocedure.

There is also a need for monitoring parameters of a BTT while the BTTcarries user traffic. The in-service loopback function provides thecapability to test parameters of a BTT, such as connectivity, delayand/or other QoS parameters, while the BTT carries user traffic. For thein-service loopback function, the loopback LSR must distinguish betweenuser traffic and a network management packet, such as an INMP. Forexample, a loopback LSR may perform a loopback procedure for a receivedINMP, while user traffic received by the loopback LSR is forwardedtowards its final destination.

FIG. 8 is a flow diagram of a preferred embodiment of the presentinvention for performing the in-service loopback function using an INMP.FIG. 8 will be described in conjunction with MPLS network 40, as shownin FIG. 3, using LER B as a loopback LSR. Loopback arrow 13 in FIG. 3illustrates a loopback procedure performed at LER B. Steps 300-302 areequivalent to steps 200-202, in FIG. 7, for implementing the pre-serviceloopback function, because BTT 10 has not been activated. In step 300,BTT 10 is established by LER A using a NM command. In step 301, an LSRin the path of BTT 10 is selected for performing a loopback procedure.For example, if the entire BTT 10 needs to be evaluated, the oppositeedge router, such as LER B, is selected. Otherwise, an intermediate LSRin BTT 10 is selected. In this example, a loopback procedure for thepre-service loopback function is activated at LER B using either anin-band or out-of-band command. After activating a loopback procedure atLER B, LER B performs the activated loopback procedure for a receivedpacket. In step 302, LER A evaluates at least one parameter of BTT 10.For example, LER A, after receiving the loopback packet from LER B,determines whether at least one parameter of BTT 10, such asconnectivity, delay, and/or other QoS parameters, is equivalent to orexceeds a predetermined standard. If one or more tested parameters pass,then BTT 10 is activated in step 303. BTT 10 is then loaded with usertraffic. If one or more tested parameters fail, notification isprovided, for example, to the NM system, and/or BTT 10 isre-established, for example, using another ER-LSP. Then, the remainingsteps for implementing the pre-service loopback function are repeated.

After BTT 10 is activated in step 303 at least one parameter for BTT 10is tested using the in-service loopback function. In step 305, at leastone BTT parameter such as connectivity, delay, and/or other QoSparameters, is tested periodically. For example, connectivity of BTT 10may be tested every second using loopback INMPs transmitted once persecond from LER A. The period between tests may be increased ordecreased depending on characteristics of the network and the desiredmeasurement. If the one or more tested parameters fail in step 305,notification is provided, for example, to the NM system, and/or BTT 10is re-established, for example, using another ER-LSP. Then, theremaining steps for implementing the pre-service loopback function arerepeated.

3. Processing INMPs

FIG. 9 is a flow diagram for processing INMPs. FIG. 9 will be describedin conjunction with MPLS network 40 as shown in FIG. 3 and using LER Bas a loopback LSR. In step 500, LER A constructs a loopback INMP. Instep 501, LER A transmits the loopback INMP downstream towards theloopback LSR, e.g., LER B. LSR 1 is the next hop on BTT 10 in thedownstream direction, and in step 502, LSR 1 receives the loopback INMP.In step 503, LSR 1 identifies the packet as an INMP using a MPLS shimheader for the INMP. The shim header and its use for differentiatingbetween user packets and INMPs is described in U.S. patent applicationSer. No. TBD (Attorney Docket No. 3493.85735), previously incorporatedby reference. LSR 1 then determines whether the received INMP is aloopback INMP, for example, by reading a command in the payload of thatINMP. In step 504, LSR 1 processes the INMP in accordance with thecommand type in the payload. For example, LSR 1 may determine from acommand in the payload that the loopback INMP is for testing at leastone parameter of the BTT, such as delay. In step 505, LSR 1 determineswhether it is the loopback LSR for the received INMP. The LSR makes thelatter determination, for example, by examining the payload anddiscovering its address in the target LSR address field of the INMPpayload. LSR 1 is not the loopback LSR, so LSR 1 transmits the INMP tothe next hop downstream, towards the loopback LSR. Steps 501-505 arerepeated until LER B receives the loopback INMP. In step 506, after LERB receives the loopback INMP and identifies itself as the loopback LSRfor the loopback INMP, LER B transmits the INMP to a next hop upstream,towards LER A. The loopback LER, LER B, may set a flag in the payload ofthe loopbacked INMP indicating that the INMP sent upstream is aloopbacked INMP.

The flow diagram of FIG. 9 is applicable for both the in-service and thepre-service loopback functions. For pre-service loopback, however, it isnot necessary to distinguish between user traffic and INMPs, because theBTT has not been loaded with user traffic. Consequently, for pre-serviceloopback, determining whether the received packet is an INMP is notnecessary.

As discussed above, in section 2, concerning the in-service and thepre-service loopback functions, a loopback INMP may carry an NM command,such as “activate loopback” or “deactivate loopback”. If an LSRreceiving an INMP containing a command, such as “activate loopback” or“deactivate loopback”, determines that the command is intended foritself, the LSR performs the command. Then, instead of transmitting theINMP upstream, towards the originating LSR, the INMP is terminated. Thisis because the INMP in this case is a command INMP as opposed to a testINMP. The LSR receiving the command may then send a signal to theoriginating LSR acknowledging that the receiving LSR has performed thecommand. Thus, in step 506, the loopback INMP may be terminated, if theloopback INMP contains a command for the loopback LSR, such as “activateloopback” or “deactivate loopback.”

The present invention is applicable to Internet backbones and enterprisenetworks. In addition, it is apparent to one of ordinary skill in theart that the present invention can be applied to any label switchingnetwork under a single technical administration, in which at least twopaths exist between two nodes. Furthermore, the present invention can beimplemented for ATM, Frame Relay, and optical networks utilizing labelswitching techniques.

What has been described are the preferred embodiments of the presentinvention. It, however, will be apparent to those skilled in the artthat it is possible to embody the invention in specific forms other thanthose disclosed in the preferred embodiments described above. This maybe done without departing from the spirit of the invention, and thepreferred embodiments are merely illustrative and should not beconsidered restrictive in any way. The scope of the invention is givenby the appended claims, rather than the preceding description.

1. A method comprising steps of: establishing a bi-directional traffictrunk; and performing a loopback function on the establishedbi-directional traffic trunk.
 2. The method of claim 1, furthercomprising a step of: evaluating at least one parameter of theestablished bi-directional traffic trunk using the performed loopbackfunction.
 3. The method of claim 2, further comprising a step of:activating the established bi-directional traffic trunk, when theevaluated parameter is any one of (1) equivalent to a predeterminedstandard associated with the evaluated parameter and (2) exceeds thepredetermined standard associated with the evaluated parameter.
 4. Themethod of claim 3, further comprising steps of: performing at least oneof (1) re-establishing the bi-directional traffic trunk using adifferent explicit route and (2) providing notification, when theevaluated parameter is not equivalent to and does not exceed thepredetermined standard.
 5. The method of claim 2, further including astep of: deactivating the loopback procedure, when the evaluatedparameter is any one of (1) equivalent to a predetermined standardassociated with the evaluated parameter and (2) exceeds thepredetermined standard associated with the evaluated parameter.
 6. Themethod of claim 2, wherein the evaluated parameter includes at least oneof connectivity, delay and other quality of service parameters.
 7. Themethod of claim 3, further comprising steps of: performing the loopbackfunction for the activated bi-directional traffic trunk; and evaluatingat least one parameter for the activated bi-directional traffic trunkusing the performed loopback function.
 8. The method of claim 7, whereinthe loopback function for the activated bi-directional traffic trunk isperformed periodically, and the evaluated parameter for the activatedbi-directional traffic trunk is evaluated periodically.
 9. The method ofclaim 8, further comprising steps of: performing at least one (1)re-establishing the bi-directional traffic trunk using a differentexplicit route and (2) providing notification, when the evaluatedparameter for the activated bi-directional trunk is not equivalent toand does not exceed a predetermined standard associated with theevaluated standard.
 10. The method of claim 9, wherein the parameterevaluated for the activated bi-directional traffic trunk includes atleast one of connectivity, delay and other quality of serviceparameters.
 11. The method of claim 1, further including steps of:selecting a label switching router in a path traversed by thebi-directional traffic trunk; and activating a loopback procedure at thelabel switching router.
 12. A method of claim 2, wherein the evaluatedparameter is evaluated for at least one portion of the establishedbi-directional traffic trunk.
 13. A method comprising steps of:activating a bi-directional traffic trunk; and performing a loopbackfunction on the activated bi-directional traffic trunk.
 14. The methodof claim 13, further comprising a step of: evaluating at least oneparameter of the established bi-directional traffic trunk using theperformed loopback function.
 15. The method of claim 14, wherein theloopback function for the activated bi-directional traffic trunk isperformed periodically, and the evaluated parameter for the activatedbi-directional traffic trunk is evaluated periodically.
 16. The methodof claim 14, further comprising steps of: performing at least one of (1)re-establishing the bi-directional traffic trunk using a differentexplicit route and (2) providing notification, when the evaluatedparameter for the activated bi-directional traffic trunk is notequivalent to and does not exceed a predetermined standard associatedwith the evaluated parameter.
 17. The method of claim 14, wherein the atleast one parameter includes at least one of connectivity, delay andother quality of service parameters.
 18. A network comprising: anoriginating router configured to transmit a packet downstream on abi-directional traffic trunk; and a loopback router configured toreceive the packet and transmit the packet upstream towards theoriginating router on the bi-directional traffic trunk.
 19. The networkof claim 18, wherein the originating router receives the packet from theloopback router and evaluates at least one parameter of thebi-directional traffic trunk using the packet.
 20. The network of claim19, wherein the bi-directional traffic trunk is not activated.
 21. Thenetwork of claim 20, wherein the originating router performs at leastone of (1) re-establishing the bi-directional traffic trunk using adifferent explicit route and (2) providing notification, when theevaluated parameter is not equivalent to and does not exceed apredetermined standard associated with the evaluated parameter.
 22. Thenetwork of claim 20, wherein the originating router activates theestablished bi-directional traffic trunk, when the evaluated parameteris any one of (1) equivalent to a predetermined standard associated withthe evaluated parameter and (2) exceeds a predetermined standardassociated with the evaluated parameter.
 23. The network of claim 20,wherein the parameter is evaluated for at least one portion of thebi-directional traffic trunk.
 24. The network of claim 19, wherein thebi-directional traffic trunk is activated.
 25. The network of claim 24,wherein the originating router performs at least one of (1)re-establishing the bi-directional traffic trunk using a differentexplicit route and (2) providing notification, when the evaluatedparameter for the activated bi-directional traffic trunk is notequivalent to and does not exceed a predetermined standard associatedwith the evaluated parameter.
 26. The network of claim 19, wherein theat least one parameter includes at least one of connectivity, delay andother quality of service.
 27. A method comprising steps of: receiving apacket traveling downstream on a bi-directional traffic trunk; andtransmitting the received packet upstream on the bi-directional traffictrunk.
 28. The method of claim 27, further comprising a step ofidentifying the incoming label of the received packet.
 29. The method ofclaim 28, further comprising a step of replacing the identified incominglabel with an incoming label corresponding to a received packettravelling upstream on the bi-directional traffic trunk.
 30. The methodof claim 29, further comprising steps of: maintaining a table of nexthop label forwarding entries; and determining the received packet's nexthop using a next hop label forwarding entry associated with the replacedincoming label.
 31. The method of claim 27, wherein the step ofreceiving a packet further includes receiving the packet at a labelswitching router, and the receiving label switching router is any one ofa label edge router and an intermediate label switching router.
 32. Themethod of claim 27, wherein the bi-directional traffic trunk is in amulti-protocol label switching network.
 33. A router comprising: aplurality of ports, one port of the plurality of ports receiving apacket travelling downstream on a bi-directional traffic trunk; andprocessing circuitry processing the packet and forwarding the packet toa selected port of the plurality of ports for transmission to a next hopupstream on the bi-directional traffic trunk.
 34. A method comprisingsteps of: constructing a packet at a router; transmitting the packetdownstream on a bi-directional traffic trunk from the routerconstructing the packet; receiving the packet at a router; anddetermining whether to perform a loopback procedure at the routerreceiving the packet.
 35. The method of claim 34, further comprising astep of: identifying the received packet as a loopback packet.
 36. Themethod of claim 35, further comprising a step of: processing thereceived packet in accordance with a command in the packet, when thepacket is determined to be a loopback packet
 37. The method of claim 36,wherein the command is associated with at least one parameter of thebi-directional traffic trunk.
 38. The method of claim 37, wherein the atleast one parameter includes at least one of connectivity, delay, andother quality of service parameters.
 39. The method of claim 34, whereinthe router constructing the packet and the router receiving the packetare label switching routers.
 40. The method of claim 34, wherein thestep of determining whether to perform a loopback procedure furtherincludes a step of determining whether the received packet is a loopbackpacket.
 41. The method of claim 40, wherein the step of determiningwhether to perform a loopback procedure further includes a step ofdetermining whether the router receiving the packet is a loopback routerfor the received packet.
 42. The method of claim 38, further comprisinga step of: transmitting the received packet to a next hop downstream onthe bi-directional traffic trunk, when the received packet is not aloopback packet.
 43. The method of claim 39, further comprising a stepof: transmitting the received packet to a next hop downstream on thebi-directional traffic trunk, when the router receiving the packet isnot the loopback router for the received packet.
 44. A networkcomprising: a bi-directional traffic trunk; an originating routerconstructing a packet and transmitting a packet downstream on thebi-directional traffic trunk; and a receiving router receiving thepacket and determining whether the receiving router is a loopback routerfor the received packet.
 45. The network of claim 44, wherein thereceiving router performs a loopback procedure, when the receivingrouter is the loopback router for the received packet.
 46. The networkof claim 45, wherein the receiving router processes the received packetin accordance with a command in the packet.
 47. The network of claim 46,wherein the command is associated with at least one parameter of thebi-directional traffic trunk.
 48. The network of claim 47, wherein, theat least one parameter includes at least one of connectivity, delay, andother quality of service parameters.
 49. The network of claim 45,wherein the receiving router transmits the received packet to a next hopupstream, towards the originating router, when the receiving router isthe loopback router for the received packet.
 50. The network of claim44, wherein the receiving router transmits the received packet to a nexthop downstream on the bi-directional traffic trunk, when the receivingrouter is not the loopback router for the received packet.
 51. Thenetwork of claim 44, wherein the originating router and the receivingrouters are label switching routers.